home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat3 / standard / end.z / end
Encoding:
Text File  |  2002-10-03  |  14.0 KB  |  212 lines

  1. END(3C)                                               Last changed: 4-12-99
  2.  
  3.  
  4. NNAAMMEE
  5.      eenndd, eetteexxtt, eeddaattaa, __eenndd, __eetteexxtt, __eeddaattaa, eepprrooll, __fftteexxtt, __ffddaattaa, __ffbbssss,
  6.      __rrtt__ssyymmbbooll__ttaabbllee, __rrtt__ssyymmbbooll__ttaabbllee__ssiizzee, __rrtt__ssyymmbbooll__ssttrriinngg__ttaabbllee,
  7.      __pprroocceedduurree__ttaabbllee, __pprroocceedduurree__ttaabbllee__ssiizzee, __pprroocceedduurree__ssttrriinngg__ttaabbllee,
  8.      __DDYYNNAAMMIICC, __DDYYNNAAMMIICC__LLNNKK, __DDYYNNAAMMIICC__LLIINNKKIINNGG, __BBAASSEE__AADDDDRREESSSS, __GGOOTT__OOFFFFSSEETT,
  9.      __ggpp, __ggpp__ddiisspp, ____rrlldd__oobbjj__hheeaadd, __rrlldd__nneeww__iinntteerrffaaccee, ____eellff__hheeaaddeerr,
  10.      ____pprrooggrraamm__hheeaaddeerr__ttaabbllee, ____ddssoo__ddiissppllaacceemmeenntt, __lliibb__vveerrssiioonn,
  11.      ____llccllddttaa__aaddddrreessss, ____llccllddttaa__ssiizzee - Loader defined symbols in a program
  12.  
  13. SSYYNNOOPPSSIISS
  14.      eexxtteerrnn iinntt eenndd[[]];;
  15.      eexxtteerrnn iinntt __eenndd[[]];;
  16.      eexxtteerrnn iinntt eetteexxtt[[]];;
  17.      eexxtteerrnn iinntt __eetteexxtt[[]];;
  18.      eexxtteerrnn iinntt eeddaattaa[[]];;
  19.      eexxtteerrnn iinntt __eeddaattaa[[]];;
  20.      eexxtteerrnn iinntt eepprrooll[[]];;
  21.      eexxtteerrnn iinntt __fftteexxtt[[]];;
  22.      eexxtteerrnn iinntt __ffddaattaa[[]];;
  23.      eexxtteerrnn iinntt __ffbbssss[[]];;
  24.      eexxtteerrnn iinntt __pprroocceedduurree__ttaabbllee[[]];;
  25.      eexxtteerrnn iinntt __pprroocceedduurree__ttaabbllee__ssiizzee[[]];;
  26.      eexxtteerrnn iinntt __pprroocceedduurree__ssttrriinngg__ttaabbllee[[]];;
  27.      eexxtteerrnn SSYYMMRR __rrtt__ssyymmbbooll__ttaabbllee[[]];;
  28.      eexxtteerrnn cchhaarr __rrtt__ssyymmbbooll__ttaabbllee__ssiizzee[[]];;
  29.      eexxtteerrnn cchhaarr __rrtt__ssyymmbbooll__ssttrriinngg__ttaabbllee[[]];;
  30.      eexxtteerrnn iinntt __ggpp[[]];;
  31.      eexxtteerrnn iinntt __ggpp__ddiisspp[[]];;
  32.      eexxtteerrnn iinntt __DDYYNNAAMMIICC[[]];;
  33.      eexxtteerrnn iinntt __DDYYNNAAMMIICC__LLIINNKK[[]];;
  34.      eexxtteerrnn iinntt __DDYYNNAAMMIICC__LLIINNKKIINNGG[[]];;
  35.      eexxtteerrnn iinntt __BBAASSEE__AADDDDRREESSSS[[]];;
  36.      eexxtteerrnn iinntt __GGOOTT__OOFFFFSSEETT[[]];;
  37.      eexxtteerrnn iinntt ____rrlldd__oobbjj__hheeaadd[[]];;
  38.      eexxtteerrnn iinntt __rrlldd__nneeww__iinntteerrffaaccee[[]];;
  39.      eexxtteerrnn iinntt ____eellff__hheeaaddeerr[[]];;
  40.      eexxtteerrnn iinntt ____pprrooggrraamm__hheeaaddeerr__ttaabbllee[[]];;
  41.      eexxtteerrnn iinntt ____ddssoo__ddiissppllaacceemmeenntt[[]];;
  42.      eexxtteerrnn iinntt __lliibb__vveerrssiioonn[[]];;
  43.      eexxtteerrnn iinntt ____llccllddttaa__aaddddrreessss[[]];;
  44.      eexxtteerrnn iinntt ____llccllddttaa__ssiizzee[[]];;
  45.  
  46. IIMMPPLLEEMMEENNTTAATTIIOONN
  47.      IRIX systems
  48.  
  49. DDEESSCCRRIIPPTTIIOONN
  50.      For the convenience of utilities and other applications that need to
  51.      access an executable in special ways, lldd(1) may create one or more of
  52.      the special symbols listed in the SYNOPSIS.  Of these, only the
  53.      symbols __pprroocceedduurree__ttaabbllee __pprroocceedduurree__ssttrriinngg__ttaabbllee, __rrtt__ssyymmbbooll__ttaabbllee,
  54.      __rrtt__ssyymmbbooll__ssttrriinngg__ttaabbllee, ____rrlldd__oobbjj__hheeaadd, ____eellff__hheeaaddeerr,
  55.      ____pprrooggrraamm__hheeaaddeerr__ttaabbllee, __lliibb__vveerrssiioonn, which are described below,
  56.      actually have associated data, which is specially created by lldd(1).
  57.      For each of the remaining special symbols listed in the SYNOPSIS, no
  58.      actual data is associated; only the address of the symbol is
  59.      meaningful.  lldd(1) sets the symbol's address to either the location of
  60.      a particular portion of the executable (such as __eetteexxtt, or __eeddaattaa) or
  61.      to the value of some other interesting parameter (such as
  62.      __pprroocceedduurree__ttaabbllee__ssiizzee).
  63.  
  64.      NOTE: To avoid their interpretation as gp-relative data, each of these
  65.      symbols must be declared as an array.  Moreover, most of these arrays
  66.      are declared to have elements of type iinntt though do not conclude that
  67.      this imposes any restrictions on the alignment of the addresses.
  68.  
  69.      The symbol versions without a leading underbar may be overridden by
  70.      applications.  If the application defines the symbol, the symbol is no
  71.      longer special and the information here is irrelevant for the symbol.
  72.  
  73.      NOTE: Many of the symbols mentioned here are release-specific and may
  74.      change meanings or disappear across releases.
  75.  
  76.      The address of eetteexxtt and __eetteexxtt are the first address above the text
  77.      segment, eeddaattaa and __eeddaattaa are the first address above the initialized
  78.      data region, and eenndd and __eenndd are the first address above the
  79.      uninitialized data region.
  80.  
  81.      The address of __fftteexxtt is the first address in the program text, __ffddaattaa
  82.      is the first address in the initialized data region, and __ffbbssss is the
  83.      first address in the uninitialized data region.
  84.  
  85.      Note that the __fftteexxtt, __eetteexxtt, __eeddaattaa, __fftteexxtt, __ffddaattaa, and __ffbbssss are
  86.      rather questionable things to depend on for programs using dso's or
  87.      having multiple text or data regions.  There is no standard definition
  88.      of the meanings of these symbols when there are multiple text or data
  89.      regions present.  For example, use of lldd options and spec files can
  90.      result in the creation of multiple text and/or data regions.  Most
  91.      programs use dso's and that means there are multiple text, data, and
  92.      bss regions in the running application.  Instead of presuming that
  93.      these symbols mean something specific, applications would be better
  94.      off using ____eellff__hheeaaddeerr and ____pprrooggrraamm__hheeaaddeerr__ttaabbllee and
  95.      ____ddssoo__ddiissppllaacceemmeenntt to determine the memory regions of whatever code
  96.      refers to the symbol. That is,  from within a dso (or main program),
  97.      ____eellff__hheeaaddeerr refers to the ____eellff__hheeaaddeerr of that dso (or main program).
  98.      One can use ddllooppeenn and ddllssyymm to access the symbols of a different dso
  99.      or, from a dso, of the main program (see the ddllooppeenn man page).
  100.  
  101.      eepprrooll is a symbol that was once used by lliibbpprrooff but is no longer used.
  102.      User code may freely define its own such symbol for any application
  103.      purpose.
  104.  
  105.      In ISO/ANSI C, the eenndd, eeddaattaa, and eetteexxtt symbols are elements of the
  106.      space of names reserved for the user.  Thus, by default these symbols
  107.      are not defined by the loader (lldd(1)).  If, however, a reference to
  108.      eenndd, eeddaattaa, or eetteexxtt is unsatisfied during the link, it will be
  109.      defined by the loader.  The address of the resultant symbol will be
  110.      identical to the address of the symbol of the same name prefixed by an
  111.      underbar. (Thus, if an unsatisfied reference to eenndd remains at the end
  112.      of the link, lldd(1) will satisfy the reference by giving it the same
  113.      address as __eenndd, which is always defined.)
  114.  
  115.      Some symbols have a dso-specific meaning.  That is, a query of the
  116.      value within a dso can get a dso-specific value:  the values are not
  117.      global, but specific to the main program or dso taking the address of
  118.      the symbol.  The dso-specific symbols are:  __ggpp, __ggpp__ddiisspp,
  119.      __pprroocceedduurree__ttaabbllee, __pprroocceedduurree__ttaabbllee__ssiizzee, __pprroocceedduurree__ssttrriinngg__ttaabbllee,
  120.      __rrtt__ssyymmbbooll__ttaabbllee, __rrtt__ssyymmbbooll__ttaabbllee__ssiizzee, __rrtt__ssyymmbbooll__ssttrriinngg__ttaabbllee,
  121.      __ddaattaa__iinniitt__ttaabbllee, __DDYYNNAAMMIICC__LLIINNKK, __DDYYNNAAMMIICC__LLIINNKKIINNGG, and __BBAASSEE__AADDDDRREESSSS.
  122.      All the other symbols are global and therefore a single value (that of
  123.      the main program) will be seen from all dsos and the main program
  124.      because of the global symbol resolution rules.
  125.  
  126.      All of the symbols beginning with __ (underbar) are reserved to the
  127.      implementation by ISO/ANSI C rules and it is unwise to attempt to
  128.      define these as global symbols.
  129.  
  130.      __ggpp is the address of the region of global data accessed by offsets of
  131.      the global-pointer register (its address is the run-time value of the
  132.      global-pointer register.)
  133.  
  134.      __ggpp__ddiisspp has the same value as __ggpp.
  135.  
  136.      When execution begins, the program break coincides with __eenndd,, but it
  137.      is reset by the routines bbrrkk(2), mmaalllloocc(3), standard input/output
  138.      (ssttddiioo(3)), the profile (--pp) option of cccc(1), etc.  The current value
  139.      of the program break is reliably returned by ssbbrrkk((00)), see bbrrkk(2).
  140.  
  141.      __DDYYNNAAMMIICC__LLIINNKKIINNGG and __DDYYNNAAMMIICC__LLIINNKK are identical.  If referred to,
  142.      they have special value generated by the linker:  0 means this code is
  143.      non-shared, 1 means the code is in a KPIC executable, and 2 means the
  144.      code is in a dso.
  145.  
  146.      __DDYYNNAAMMIICC is a symbol which is no longer used.
  147.  
  148.      __BBAASSEE__AADDDDRREESSSS is the virtual address of the first loadable segment in
  149.      the dso/executable.
  150.  
  151.      __GGOOTT__OOFFFFSSEETT is no longer used or set.
  152.  
  153.      __rld_obj_head is set to the virtual address of a pointer to the list
  154.      of dso's in a 32-bit executable.  See also <oobbjj..hh> and <oobbjj__lliisstt..hh>
  155.      and rrlldd(1).
  156.  
  157.      __rrlldd__nneeww__iinntteerrffaaccee is set to the address of a function within rrlldd that
  158.      implements various run-time linking facilities.  See rrlldd for further
  159.      information.
  160.  
  161.      ____eellff__hheeaaddeerr is set to point to the elf header of the executing object
  162.      or dso.
  163.  
  164.      ____pprrooggrraamm__hheeaaddeerr__ttaabbllee is set to point to the program header table of
  165.      the executing object or dso.
  166.  
  167.      ____ddssoo__ddiissppllaacceemmeenntt is set to point to a 32-bit word (in a 32-bit
  168.      program) which is the amount the executable or dso has been moved by
  169.      rrlldd at run-time.
  170.  
  171.      __lliibb__vveerrssiioonn is set to point to the address of a 32-bit integer.  The
  172.      value of the integer is 0 normally.  It can be non-zero with
  173.      applications linked -abi and -cckr which can affect slightly the
  174.      behavior of abi applications calling ssccaannff, llddeexxpp, or aattooff.
  175.  
  176.      ____llccllddttaa__aaddddrreessss is set to the address of a special section used to
  177.      keep thread-local data for MP programming.  See the MP documentation
  178.      for further information.  This symbol is not applicable to
  179.      applications compiled as 64-bit programs.
  180.  
  181.      ____llccllddttaa__ssiizzee is set to the size (in bytes) of the special section
  182.      referred to above.  This symbol is not applicable to applications
  183.      compiled as 64-bit programs.
  184.  
  185.      The loader defined symbols __pprroocceedduurree__ttaabbllee, __pprroocceedduurree__ttaabbllee__ssiizzee,
  186.      and __pprroocceedduurree__ssttrriinngg__ttaabbllee refer to data structures of the runtime
  187.      procedure table.  The procedure table data structures are built by
  188.      lldd((11)) only if they are referenced.  See the include file <ssyymm..hh> for
  189.      the definition of the runtime procedure table and see the include file
  190.      <eexxcceeppttiioonn..hh> for its uses.  These symbols are not applicable to
  191.      applications compiled as 64-bit programs.
  192.  
  193.      The loader defined symbols __rrtt__ssyymmbbooll__ttaabbllee, __rrtt__ssyymmbbooll__ttaabbllee__ssiizzee,
  194.      and __rrtt__ssyymmbbooll__ssttrriinngg__ttaabbllee refer to data structures of the runtime
  195.      symbol table.  The runtime symbol table structures are built by lldd((11))
  196.      only if they are referenced.  The runtime symbol table includes all
  197.      stProc and stGlobal symbols and is used by the kernel for dynamically
  198.      loadable kernel modules.  See the <ssyymm..hh> include file for the
  199.      definition of the runtime symbol table.  These symbols are not
  200.      applicable to applications compiled as 64-bit programs.
  201.  
  202. SSEEEE AALLSSOO
  203.      lldd(1), cccc(1), ff7777(1), ppcc(1), rrlldd(1)
  204.  
  205.      bbrrkk(2)
  206.  
  207.      mmaalllloocc(3C)
  208.  
  209.      mmllooaadd(4)
  210.  
  211.      This man page is available only online.
  212.